[Design] Event-driven vs Request-driven

Summary

Request-driven systems perform work in response to direct calls. Event-driven systems publish facts and let subscribers react independently.

Interview Points

• Request-driven is simple for command/query flows.
• Event-driven improves decoupling and extensibility.
• Events represent facts that already happened.
• Event-driven systems need schema evolution, ordering, retries, and idempotency.
• Use events for side effects, integration, and workflows that do not require immediate response.

2-3 Minute Interview Script

“A request-driven system is direct: service A calls service B and waits for a response. That is simple and works well when the caller needs an immediate answer.

An event-driven system publishes events like OrderPlaced or PaymentCaptured, and other services react independently. This decouples producers from consumers and makes it easier to add new behavior without changing the original service.

The tradeoff is complexity. Events are asynchronous, so the system becomes eventually consistent. Consumers need idempotency, retries, dead-letter handling, and schema evolution.

In an interview, I would use request-driven communication for immediate decisions and event-driven communication for downstream side effects, integrations, and audit-style workflows.”

Follow-Ups

• What belongs in an event?
• How do you version event schemas?